Hi people, sorry for all the unanswered questions and ideas. I needed to take a few weeks off, do some real work for real money. 
However, I plan to add new things to Airio or improve old ones or debug the code. As you can see from the changelog page, some smaller yet maybe usable new things appered already and will be available in 2.3.5. I have new features in mind, but they are all quite complicated, maybe code cleaning (such as renumbering all buttons) will be necessary, and this is tedious and error-prone. Anyway, here are my comments to past posts:
Airio standard bans (in FULL version) and permanent bans (using BName) are ignored for limads level EnableBanLimited (formerly EnableBan) and above, as set in CFG file.
I'd suggest using for this the special points for "driving" (!ptd) and for "playing" (!ptp). These will accumulate all points, but only if that server uses StorePointsPlaying=true resp. StorePointsDriving=true. So, you may have both these set to false on all servers by default and change it temporarily only on one server for the special occassion. Once the even closes, you use false again. If true, all points from any track/car combination are accumulated into these numbers. The total points are also shown (with position) in !pi output.
Well, you can send !cfg StorePointsPlaying=true at a special time (in FULL version), but it is not possible to say that this should be active say for just 6 races. If you do not know when the champ races finish, then I'm afraid the only option to turn off playing/driving points is to do this manually (e.g. by !rld).
FULL version of Airio allows to limit higher car types using rank (points) and licence (lap time) and safety rating. Faster cars may be assigned categories with each one evaluated separately - there may be one winner of TBO category and one winner of GTI category in the same race. I believe this works quite well on the LR server. Also limiting car types by safety level should work though I did not test it for some time now. This means you may have GT2/GTR combined server with GTR cars available only if you have reasonable safety rank (and optionally certain rank, and optionally certain licence).
Currently all custom cars and categories can have only exactly 3 characters. This limitation makes parsing easier and is in accordance with principles used in LFS. Still, Airio code may be adjusted to allow longer names/codes, there's nothing preventing this.
Hm, that's interesting. The SpecAfterFinish is intended primarily for layout hotlapping (such as is used on Cone Challenge). I'd need to see more closely how it could be used in qualifying mode.
Good about the run! When Airio is used locally it should really run without losing connection. Still, I'm not sure how it could ever cause crash to the whole server, regardless of how many times if loses connection. If you'll have any more troubles, let me know.
Thanks for info, I've seen it in the past, but I don't think it something bad?
Well, as I wrote above, just one or two smaller things currently. However soon I'd like to add things that will be very hard to test thoroughly. E.g. universal pitlights (showing RED sometimes when entering track from pitlane and spectating people for ignoring this) should kick in only under special circumstances which are hard to create. For this it is best to let Airio run on some popular server, watch closely and see if there was any false warning/alarm). But this feature, while no doubt useful, is not as easy to implement... Still, some detection rutines are almost ready, I'd like to enter basic testing phase soon.
Track rotation is quite old feature and I believe it works reliably. There's no magic in setting it up, you'll just use 2 items in appropriate SRV file. Here's an example:
If you're on any of the tracks in rotation, then every 5 races the track will automatically move to the next one, changing lap count and car types as specified.
Yes, Airio can use the race length setting in hours and change it into minutes. (Note that the race length will in LFS [F12] still show as hours, which may cause some confusion.) To use racing for 15 minutes plus one lap use !len -15 command. Acceptable values are from 1 to 96. Note the negative value indicating minutes. Positive values represent laps.
Important: If you use !len with negative number (to race for minutes) and then want to return to races for laps, use !len again, this time with positive value, required lap count. Using /laps= will leave racing for minutes active in Airio, which you do no want.
However, I plan to add new things to Airio or improve old ones or debug the code. As you can see from the changelog page, some smaller yet maybe usable new things appered already and will be available in 2.3.5. I have new features in mind, but they are all quite complicated, maybe code cleaning (such as renumbering all buttons) will be necessary, and this is tedious and error-prone. Anyway, here are my comments to past posts:Airio standard bans (in FULL version) and permanent bans (using BName) are ignored for limads level EnableBanLimited (formerly EnableBan) and above, as set in CFG file.
I'd suggest using for this the special points for "driving" (!ptd) and for "playing" (!ptp). These will accumulate all points, but only if that server uses StorePointsPlaying=true resp. StorePointsDriving=true. So, you may have both these set to false on all servers by default and change it temporarily only on one server for the special occassion. Once the even closes, you use false again. If true, all points from any track/car combination are accumulated into these numbers. The total points are also shown (with position) in !pi output.
Well, you can send !cfg StorePointsPlaying=true at a special time (in FULL version), but it is not possible to say that this should be active say for just 6 races. If you do not know when the champ races finish, then I'm afraid the only option to turn off playing/driving points is to do this manually (e.g. by !rld).
FULL version of Airio allows to limit higher car types using rank (points) and licence (lap time) and safety rating. Faster cars may be assigned categories with each one evaluated separately - there may be one winner of TBO category and one winner of GTI category in the same race. I believe this works quite well on the LR server. Also limiting car types by safety level should work though I did not test it for some time now. This means you may have GT2/GTR combined server with GTR cars available only if you have reasonable safety rank (and optionally certain rank, and optionally certain licence).
Currently all custom cars and categories can have only exactly 3 characters. This limitation makes parsing easier and is in accordance with principles used in LFS. Still, Airio code may be adjusted to allow longer names/codes, there's nothing preventing this.
Hm, that's interesting. The SpecAfterFinish is intended primarily for layout hotlapping (such as is used on Cone Challenge). I'd need to see more closely how it could be used in qualifying mode.
Good about the run! When Airio is used locally it should really run without losing connection. Still, I'm not sure how it could ever cause crash to the whole server, regardless of how many times if loses connection. If you'll have any more troubles, let me know.
Thanks for info, I've seen it in the past, but I don't think it something bad?
Well, as I wrote above, just one or two smaller things currently. However soon I'd like to add things that will be very hard to test thoroughly. E.g. universal pitlights (showing RED sometimes when entering track from pitlane and spectating people for ignoring this) should kick in only under special circumstances which are hard to create. For this it is best to let Airio run on some popular server, watch closely and see if there was any false warning/alarm). But this feature, while no doubt useful, is not as easy to implement... Still, some detection rutines are almost ready, I'd like to enter basic testing phase soon.
Track rotation is quite old feature and I believe it works reliably. There's no magic in setting it up, you'll just use 2 items in appropriate SRV file. Here's an example:
RotateRaces=5
RotateTracks=BL2|3|XFG+XRG > FE5|4|TBO > FE6|5|RAC+LX4If you're on any of the tracks in rotation, then every 5 races the track will automatically move to the next one, changing lap count and car types as specified.
Yes, Airio can use the race length setting in hours and change it into minutes. (Note that the race length will in LFS [F12] still show as hours, which may cause some confusion.) To use racing for 15 minutes plus one lap use !len -15 command. Acceptable values are from 1 to 96. Note the negative value indicating minutes. Positive values represent laps.
Important: If you use !len with negative number (to race for minutes) and then want to return to races for laps, use !len again, this time with positive value, required lap count. Using /laps= will leave racing for minutes active in Airio, which you do no want.
Hm, I just checked the filter with following settings: SetupAbsAllow=false, SetupAbsForce=false and I was correctly spectated when using ABS, allowed to join without ABS...
Hi! If you return by several pages in this thread, you'll find the settings discussed, because it unfortunately includes a serious issue that's not possible to resolve with the currently available data. Anyway, I'll repeat the problem below to save you the time of looking for more info...
Hm, I just did some tests and it worked for me as expected. You correctly say that CheckSetup must be set to true, or car/driver setting are not checked. Default SetupTcAllow=true then says TC is allowed and default SetupTcForce=false does not force the use of TC. Here's the possible combinations:
1) SetupTcAllow=true, SetupTcForce=false : Anyone can join with TC on or off.
2) SetupTcAllow=false, SetupTcForce=false : TC is not allowed, when joining with TC you are spectated.
3) SetupTcAllow=true, SetupTcForce=true : TC is required, when joining without TC you are spectated.
4) SetupTcAllow=false, SetupTcForce=true : This setting does not make sense, because you prohibit TC by one command and force it by other. DO NOT USE, cars will always be spectated.
I checked the code and did experiments with all combinations, it worked as it should for me. HOWEVER there's an important point seriously limiting the use of all the above TC settings. The problem is the check is possible only when joining track. Unfortunately LFS does not report TC state changes once the car is on track.
The problem is TC is part of car setup, not like e.g. auto gears, which are part of player setup. If someone turns on/off automatic gears on track, the change is reported and thus e.g. a policy of no automatic gears can always be enforced. If someone changes TC status once on track, Airio has no way to know.
When trying to solve the issue I went into really weird solutions, like asking for player and car data periodically, but unfortunately even this did not work, always TC state when joining track was reported, not current TC state.
I'd call it a LFS inconsistency bug, TC should fall into the same category as auto gears and then we'll have no troubles. But as it is now, TC is stored and can be checked only on race join, later changes are not visible to server/Airio.
Great! And thanks as well.
OK, please also use the latest available FREE version, which is 2.3.4a. The QuickReconTries is a complicated matter. Please set it to 1 for now. But I know there may be problems with this setting, quick reconnect after forced disconnect may sometimes fail badly, leading to very weird Airio state. Mostly it works OK, but when there's really unfortunate sequence of events, it has a tendency to fail. I'll try to watch closer what's going on there, but it is a state that's nearly impossible to recreate and watch closely...
Both things have very probably a common cause. Current default Airio files allow any operations on stats (such as !clr or !del) only to limads level 5. The catch here is, and I would need maybe to change the default settings, you cannot use super-admin (limad 5) in FREE version, such setting is turned to limad 4.
So you need to use lower level to be able to change stats. Open CFG file, find EnableStats items and set it to =4. Type !rld and the above mentioned operations should work for you. To protect stats, it may be good to change the setting back to 5 later.
You could be actually very right, I'll check what happens in case there are numerous breaks in server connection, maybe some listening/sending threads are not closed properly but new ones are started...
The important thing is where you set/type the /insim= LFS command. It MUST be typed directly on server (that is in dedicated server console) or set specifically in server configuration. If you connect to server as a client and then type /insim=, you're setting the InSim port for your client. Airio finds the port open and connects, but to your client.
First start the dedicated server, type e.g. /insim=29999 in its text console. Then run Airio, it should connect to server. Then connect to server as a client and it should be OK...
Hi Roby! One of the basic Airio requirements is to use dedicated host. If someone uses graphical host, meaning he starts host directly from the game, then some things will not work for the host quite OK, because connection 0 (the host) is not expected to drive, it is handled in a special fashion.
However, your picture is another case. Here you've connected Airio directly to your LFS instance. That's why there are the failed messages, you've connected it to client (yourself) and not to server. And client connections do not support messages to other connections/players.
If you want to use Airio, even e.g. for home practicing, I'd suggest starting dedicated host and connecting Airio to that host first. Then you can connect with LFS to the host and everything will work as it should.
Yes, that is possible, you just type !sb xrt+rb4+fxo (note that !sb stands for server best and it is exactly the same as !top). To simplify typing, default Airio files (TCD file, to be exact) specify TBO car category and this allows you to type just !sb tbo to get the same output.
If you'll always have on that server only TBO cars, you may use StandardCars item in the appropriate SRV file and set it to =TBO. Any time a car type (or group) is not specified, TBO is supplied, and that means you can then type only !sb and see all TBO cars. Still, !sb fxo will give you only FXO lap times.
Last edited by EQ Worry, .
Disconnects from local run are very, very rare. Please check your TCPSendDelay setting in CFG file. If it is set to 0, use at least 5, if it is already set to 5, try 10. These are milliseconds to wait between sending any two messages (commands) to server, which then has enough time to process it.
I do not see any way Airio could "re-create" itself and run in many instances at once. However, FireDaemon is certainly an application that can start by itself new processes, even several Airio instances. But a socket error is captured in Airio and handled, it is not a service breakdown. I'd suggest 2 things here: 1) Get the latest Airio, that is 2.3.4a, because it contains new code in the internal InSim library to capture serious errors resulting from very bad packets that look like coming from server but in fact are completely wrong. 2) Check FireDaemon settings, maybe even change them so that the service (Airio) is not restarted automatically or it is but only when it really completely crashes. But in fact this should never happen, at least not with the latest compile.
Logs are always helpful, especially if they come from the day when several Airio instances were suddenly running, causing memory depletion and then server crash. But I have to say e.g. on AirAttack we're also running Airio under FireDaemon, for days and weeks in one haul, without any problems...
Thanks for these tests. I'll send you a link to special Airio versions, both FREE and FULL that contain additional syslog messages so that we can see where exactly the problem is.
The interesting fact is that it is Mono that fails for some reason, not Airio. Bugs in Airio are captured, stored into log, the applications stays running. In your case something fails in Mono and the whole process is stopped.
My friend was experimenting with Mono. Using 2.0 he had no problem, using 2.2 he had once the same problem as you. But then he reinstalled Mono, or upgraded to newer version, I'm not sure, and suddenly there was no problem again. All this with one and the same Airio executable...
UPDATE: If I understood the test results correctly, it seems the latest Airio is working fine with Mono 2.0 and Mono 2.4. Strangely enough, it does not like Mono 2.2, causing it to crash...
The interesting fact is that it is Mono that fails for some reason, not Airio. Bugs in Airio are captured, stored into log, the applications stays running. In your case something fails in Mono and the whole process is stopped.
My friend was experimenting with Mono. Using 2.0 he had no problem, using 2.2 he had once the same problem as you. But then he reinstalled Mono, or upgraded to newer version, I'm not sure, and suddenly there was no problem again. All this with one and the same Airio executable...
UPDATE: If I understood the test results correctly, it seems the latest Airio is working fine with Mono 2.0 and Mono 2.4. Strangely enough, it does not like Mono 2.2, causing it to crash...
Last edited by EQ Worry, .
Uhm.
Version 2.3.4 added things that solved certain requirements and since I released it some corrections were needed fast. This is all done now and I'm waiting for possible feedback - mostly bug reports. I have no issues that need quick solution now, as far as I can see the new version runs smoothly. And that means I can get back to my real work for a time. I have some nice proposals to implement, such as a warning system or universal pit exit lights, but they're no easy things so I need a small break with real work to keep my family going before plunging back into these. Are your troubles always of the same nature, that means broken connection? Because that is what the "error" is. It is not a bug, it is a condition when the connection to LFS server cannot be established or gets broken.
Connection troubles may appear when running Airio remotely, by that I mean running it on some other computer (e.g. from your home PC). There are quite a lot of data to be transferred in both directions and if using remote connection, it may fail. In this case server may disconnect Airio, just as it sometimes disconnects other people (connection lost).
My first suggestion would be to run Airio either remotely from a very good (fast, reliable [wifi is not an option]) connection or best run it locally, right on the computer where LFS server runs. Local connection errors are then very very rare events. Hm, in fact I'm not sure I've ever seen one.
If you're running Airio locally already and still get many disconnects, well, then it would require more detailed analysis. Any other troubles you're fighting with? Never hesitate to let me know, either through private message or this thread. Best is also to have Airio log ready in case there's some error.
We did some testing of the latest Airio 2.3.4 under Linux with Mono and everything worked as expected, so I'm really not sure where could be the trouble...
As Bunder shows (thanks!) it is not in fact a command, but a configuration option. The example shown means that FXO will be restricted by 3 percents on all tracks... People with lower (none) restriction will be spectated and show what is expected.
I'm afraid Linux is not my field, but I've forwarded your post to my friend, a Linux guru, maybe he'll have some ideas. Anyone else having suddenly troubles with Airio 2.3.4 running on Linux?
Another suggestion may be to use the !ver command (or some other) directly in server console (or while connected, but with output to chatlines instead of buttons) and see if some lines are shown before the error.
Another suggestion may be to use the !ver command (or some other) directly in server console (or while connected, but with output to chatlines instead of buttons) and see if some lines are shown before the error.
Airio 2.3.4 is released. It corrects (hopefully) issues from previous compiles and also adds new things suggested and required by some people, such as:
- Limads definable on server level.
- Grid order manipulation after qualification and possibility to require pitting/spectating only from pitlane.
- Support for instance and server descriptions shown as tooltips on Airio servers page.
- Support for time-locking only in race.
- Settable race restart/end countdown period, also support for e.g. !re 60.
- Better support for registered usernames for some event.
- Continuous help screens for limads and admins.
- Possible limad descriptions and showing driver status.
- Preferential race join to certain number of people with best session times, e.g. !sa 24.
- Server and LFSW lap times overview commands, !pbs and !prs.
- Possible spectate for car reset in race, while free reset is allowed in practice/qual.
Well, I have no experience with such systems, so I'm not sure what advantage they could present...
The "improper DT" is in version 2.3.4 (currently running on FM) limited only to BL2, so I think it should cause no more troubles.
What you basically need is to manipulate with LimitToRegistered item in SRV file. There are several ways you can do that: Using !cfg command manually for temporary change. You may also put such command into a SET file together with other settings required for an event and call all at once using !si x. Scheduled commands (in FULL version) will also work, both !cfg and !si. Just beware that doing !rld reverts server settings back to defined defaults, erasing all changes done by !cfg commands.
Interesting idea, surely. Also possible, I think, but requiring two, maybe three new items in SRV file. And also two new messages, one saying privately to the additional connection being kicked why this action was taken, one announcing the reason (optionally) to everyone else on server. Question is what can be done about repeated connects, I guess nothing. Banning anyone for trying to connect to a server with slots limited by limad level is not an option. So in the end you may see MANY kicks from virtually full host, which could become tiresome for everyone connected and trying to connect.
Connecting people will have no way to know if they will not be kicked suddenly, which may lead to desparation, later to hatred (no doubt towards the stupid tool that's kicking them for stupid reasons). So I'm kind of reluctant to implement this feature, I see it as too limiting and not exactly transparent.
So, maybe not so interesting idea after all. Limads will be able to race if they have level at least equal to AllowJoining in CFG file (or higher). With sufficient level the following joining checks are skipped for them: registered names, time lock, repeated joining, licence level, rank level, safety level. Defined intake/mass restrictions and prohibited cars are always applied to everyone, no exceptions.
Ah, yes, I'd like to, but I'm short of manpower...
Eh, nothing serious, just limad levels printed for test purposes, sorry, I forgot to remove one command. It is now corrected in the latest FULL version...
Heh, no doubt that looks very stupid, sorry! If I remember correctly there was this idling bug on tracks with 0 nodes (such as AU1 or BL3) in a very early release of 2.3.3, but I think the compile available now already solves it. If you can, please try downloading 2.3.3 again and see if the problem is still there. Also I plan to release 2.3.4 today, so maybe you can wait a few hours and get the latest... Also there's always the option to disable idling check (in SRV, CheckIdling).
The format of track rotation is track|cars|time, you can omit time (laps) or also cars, but not just cars. So the entry track|time is not recognized, try putting also cars in the middle, then it should work...
As for spectating on next race start (if you use reversed grid, it could be the last winner that is spectated), it is connected with "limit overcome" feature. 12th on grid is spectated if there are 13 or more connections. If then 2 or 3 cars join at approximately the same moment, then it is possible to have 13 or even 14 cars on track even in demo. A little bug in 2.3.3 caused the spectate to always happen, regardless of LimitOvercome setting. It is corrected now for some time.
The idling check always runs only during race. I cannot believe someone was spectated for idling after race, I see no way that could happen (but I can be blind of course). Very rarely someone could be spectated during race while he is driving. This is mostly the case when for some (unknown to me) reason the server does not see the driver moving. His arrow is not moving in the little map, his car stays in pits in Remote, yet the driver says he was moving, leaving pits. But no one can se him, not even Airio, so he gets spectated after a while. This is very exceptional condition, but I can't do anything about it.
The idling check always runs only during race. I cannot believe someone was spectated for idling after race, I see no way that could happen (but I can be blind of course). Very rarely someone could be spectated during race while he is driving. This is mostly the case when for some (unknown to me) reason the server does not see the driver moving. His arrow is not moving in the little map, his car stays in pits in Remote, yet the driver says he was moving, leaving pits. But no one can se him, not even Airio, so he gets spectated after a while. This is very exceptional condition, but I can't do anything about it.
I think it was correct. A driver pitted, remained in pits. Yet Airio specced him like he was still on track, which was not correct. The driver would see only a little change, Join button would turn to OK. (And if midrace join is disabled, he would not be able to join.) I hope I corrected this behavior now.
This means a character code was not found in internal LFS <-> Unicode conversion tables. You may ignore these warnings. In time I want to fully support conversion of LFS character codes to Unicode and back (!), including Asian charsets, but it is a tricky matter...
Ah, right, sorry. It seems I was doing some experiments with pitlane and forgot to activate back one parameter chance in the test version you're using. Thanks a lot for spotting this!
Last edited by EQ Worry, .
Basically, warning say some state or condition was not expected, but it is nothing serious. In this case people disconnected without first leaving the race. This was caused by the fact they disconnection from lobby after end race was called. Airio expects that all disconnecting people have PID (player ID, yes) equal to zero. This was not the case, that's why the warning. I did a small update in Airio code, replacing /clear command carries out on race end by !sall, spectating all people. Some testing would be necessary though to see it is OK...
Strange in your output is this line:
09.09.12 12:10:45 #1 This command needs a parameter
It would be good to see what LFS command it was and then see why it had no parameter (see server log, optionally turn on server logging to capture all / commands into Airio log for easier debugging). My guess is this was /track= command. Note that there's no message about track being loaded in your output. People waited for some 30 seconds, nothing happened, and they disconnected.
Eh, yes, it looks like FE1/2 pitlane is really short, and if there's a small delay when entering pitlane (and that is very often), the exit follows less then 6 seconds later and it is seen as DT cheating. New code limits the check to BL2 only as it is probably the only track where DT cheat can be done to unfair advantage.
I guess you're right. Certaily the /spec command to send him off the track was issued (maybe you can check this in server log?), unfortunately LFS server ignored that command.
It happens sporadically, especially with /restart and /end commands. For these two I added special timers checking if the command was actually carried out, repeating it several times if necessary.Up till now I've never seen /spec command being ignored, but obviously it may happen. A solution would be to check some 5 seconds later whether the driver was really specced (or kicked, I guess /kick could be also ignored), repeating the command several times to be sure the required action is carried out. Eh...
Data offered by InSim contain no information about IPs of connections. The FULL version of Airio can listen to changes in server log files (if server directory is correctly specified in Airio config), grab IP addresses from there and assign them to connections. Currently only checking for doubled IPs (and kicking for that) is supported.
Earlier people asked me if banning by IP would be possible. Well, yes, to a certain extent and with some limitations. First, the listening mechanism is not guaranteed to always capture the correct address. I'd say it would work in 99 percents of connections, but when actions align badly it may fail.
Also many different people use one privider and are seen as using one IP. Banning by IP may hit many people that just happen to use the same provider as some stupid crasher. A possible solution would be to ban IP e.g. for just one hour, so that the crasher cannot connect back immediatelly with different username, but others are not excluded for too long.
All in all, FULL version of Airio can capture IP addresses. The usage is currently limited though due to other considerations. Still, the possibilities to display IPs and do more actions based on IPs are open, adding such things would not be too complicated.
Uhm, support for FIL files was removed several months ago, about 6 I'd say. The file contained separate items for filters, but there's been too many external files then and people were a bit lost as to where specific items are. So FIL was merged back to SRV.
I'd suggest you take a look at the current Airio default config files. There are three basic ones: CFG containing data valid for whole instance (several servers), TCD containing (hierarchical) track/car data, and SRV containing server-specific information.
This arrangement has not changed recently and no change is planned, so if you could convert your current files to the format the default files use, future updating (using file comparison tools) will be much easier for you. In case you prefer filers (or anything else, e.g. all custom texts) in some other files, you can always use IncludeFile item and point to custom filename.
Yes, but need to use at least the EN file from latest language pack. This file goes (after !rld) to msg directory. Open the file, find the text you want to change, change it, save file, type !rld, check...
Hmmm, I must ask Failure to send me the log and check closer what kind of trouble this was. Basically "improper DT" means you've spent in the pitlane surprisingly short time, something less than 5 seconds. It is there to prevent nasty DT cheating possible most notably on BL2. Maybe it could misfire in situations when there's a lag while entering pitlane, or the lane entry packet is lost somehow, and the pitlane is also very short. I'll check and try to correct this...
OK, I checked, this works too as expected. But I think I know where's the trouble.
If you specify XR3|XRT,0,113 in TCD file, you're basically creating a new car type. Anyone joining with XRT with 113 or more kgs of additional mass will be seen as joining with XR3 and Airio will keep separate stats for this type of car. But this definition does not say, that XRT cannot be used, so anyone with less than 113 kgs will be seen as joining with XRT and nothing will be done. Both XRT and XR3 are allowed. There are two options to disallow unrestricted XRT:
1) In SRV file you may use ProhibitedCars item and type there XRT. Anyone joining with pure XRT will be spectated for bad car type. All joning with XR3 will be able to stay on track. The disadvantage of this method is you need to create additional text to explain why is XRT disallowed and what needs to be done. (Experienced Airio users might type !cars and see all defined custom cars and act based on that info, but there is not as many of us around.
)
2) In TCD file apply AddedMass of 113 kgs to XRT on all tracks. People joining with XRT will be spectated and will see in big buttons and colors what mass is required. And once they use that mass, Airio sees them as joining with XR3. Understood?
If you specify XR3|XRT,0,113 in TCD file, you're basically creating a new car type. Anyone joining with XRT with 113 or more kgs of additional mass will be seen as joining with XR3 and Airio will keep separate stats for this type of car. But this definition does not say, that XRT cannot be used, so anyone with less than 113 kgs will be seen as joining with XRT and nothing will be done. Both XRT and XR3 are allowed. There are two options to disallow unrestricted XRT:
1) In SRV file you may use ProhibitedCars item and type there XRT. Anyone joining with pure XRT will be spectated for bad car type. All joning with XR3 will be able to stay on track. The disadvantage of this method is you need to create additional text to explain why is XRT disallowed and what needs to be done. (Experienced Airio users might type !cars and see all defined custom cars and act based on that info, but there is not as many of us around.
)2) In TCD file apply AddedMass of 113 kgs to XRT on all tracks. People joining with XRT will be spectated and will see in big buttons and colors what mass is required. And once they use that mass, Airio sees them as joining with XR3. Understood?
Aaaah, that's something different than I was checking, you're using mass to create a custom car. I'll check this in a short while, there may be some hidden bug, I believe no one was using weight this way yet...
To be continued...
To be continued...
Hi! I just checked and it works for me as expected. Example configuration in TCD file:
Track=
Car=FBM
AddedMass=1This will require at least 1 kg added to FBM on all tracks. People without this mass are spectated, reason stated.
For the handicaps check to run two conditions must be met: 1) Basic Airio checks must run. You can see that after typing !ch. 2) Handicaps check must be turned on. See CheckHandicaps item in appropriate SRV file.
Otherwise, no one is excluded from this check (but to be sure, try to connect without admin/limad privileges).
InSim data offer no information about fuel level in cars, much less about the setup. And Airio depends on InSim data available on the server. So, the simple answer is no, fuel level cannot be checked.
Concerning car setup, there is a single parameter available, and that is if Symmetric Wheels are used. This parameter is used in Airio and you may require all cars to have symmetric wheels (the setting is in Pit -> Tyres). All other car setup things are strictly private, not available to server. So this basically cannot be checked either.
FGED GREDG RDFGDR GSFDG